[レポート] FF16の超大規模カットシーン制作の裏側。独自ツールによるワークフロー整備の紹介セッション #CEDEC2023 #classmethod_game

入井啓太

2023.08.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、ゲームソリューション部の入井です。

この記事ではCEDEC 2023で発表されたセッション「FINAL FANTASY XVI：カットシーン制作のためのツールパイプライン」について、内容のまとめとその所感を書いていきます。

セッションの概要

FINAL FANTASY XVI：カットシーン制作のためのツールパイプライン | CEDEC2023

本セッションでは、12時間を超える、FINAL FANTASY XVIのカットシーンを制作するために開発したワークフローとパイプラインを解説します。FINAL FANTASY XVIの大規模開発であるがゆえに発生したワークフローの問題を紹介し、その解決方法を解説します。また、そのワークフロー・パイプラインを支えるために開発したツールの全体像について、説明し、一部のツールについてより詳細に解説をしていきます。

講演者

岩渕　栄太郎氏

株式会社スクウェア・エニックス

第三開発事業本部

リードテクニカルアーティスト

坂本　厚史氏

株式会社スクウェア・エニックス

テクノロジー推進部

テクニカルアーティスト

FF16のカットシーン制作

用語の紹介

最初に、セッションの中で使用される用語についての説明がありました。

FF16の中では様々なイベントシーンがありますが、今回のセッションではカットシーンと呼ばれるシーンの作成方法について取り扱っています。

カットとショットという用語についても説明がありました。映像業界では、ここで言うカットはシーケンス、ショットをカットと呼んでいることが多いそうです。

カットシーン制作のための独自のツールとして、FF16のプロジェクトではCutEditorというものが使用されています。

こちらのツールについての詳細は、別のセッションで紹介されていました。

FINAL FANTASY XVI：大規模ゲーム開発に向けて開発環境の取り組み | CEDEC2023

様々なプロジェクトの課題の発生

課題の説明にあたって、まずは今回のプロジェクトの規模について説明がありました。ゲーム中のカットシーンの時間は合計で12時間ほどあり、カット数も349とかなりのボリュームがだったとのことです。

※以下の画像のラベルとはセリフの数のこと。

この規模の制作プロジェクトを進めるにあたり、様々な課題が発生しました。

最初に紹介されたのは、ワークフローの複雑さについてです。

今回、多くの関係者がカットシーン制作のタスクを順番にこなしていけるように、ステージ制と呼ばれるワークフローが構築されました。

各ステージは、多くの子タスクによって構築されています。例えば、Stage2のコンテでは演出方針を決めるために最初にコンテを作成し、その後各カットで必要なアセットの発注を行います。特にタスク数の多いStage5のレイアウトでは、前ステージで作成したモーションキャプチャデータの実装から始まり、様々なチェックを行ったり、VFX・ライティング等への発注を行っています。Stage11の最終確認でプロデューサー・ディレクターによるチェックが通ることで、カットシーンのデータは完成となります。

上記のように、制作のための工程が多いことから、作業を適切に回すためのワークフローと効率を上げるためのツールの整備は必須でした。

次に挙げられたのが人材についての課題です。

TA（テクニカルアーティスト）の数自体は他のプロジェクトと比較すると多かったのですが、カットシーン以外の役割も兼務しているTAが多く、カットシーン制作ツールを開発するために必要な人員は不足気味でした。

また、カットシーンの量が膨大であることもあり、スキルセットを揃えた形でアーティスト人材を集めることができず、ツールの選定にあたって意見の衝突が発生してしまいました。

その他にもプリプロ（実制作前の準備）段階の成果物にMayaのものとMotionBuilderのものが混在しており、締め切りを考慮するとこれらのデータを活かせるワークフローを構築しなければならない、という課題もありました。

当初、MayaとMotionBuilder それぞれの成果物をそのまま実機実装できるワークフローを求められましたが、この場合ツール開発とサポートの工数が2ソフト分かかることになり、人材が不足していることから実現は不可能でした。

MayaとMotion Builderどちらかに統一するというのも難しく、新たなワークフローを構築することが必要になりました。

MB to Mayaワークフローの構築

上記の課題を解決するため、MB to Mayaワークフローというものが新しく構築されました。これは、Motion BuilderとMayaのデータ連携を含めた、データ出荷までの作業全体を指したワークフローで、Mayaの操作に不慣れなMotionBuilderの作業者をサポートできるように整備したとのことです。

基本的な流れとして、レイアウトの納品前やツールが必要な作業は必ずMayaを使用するルールを作りました。これにより、ツール開発はMaya向けにするだけで良くなり、ツール開発のためのコストを削減できました。

一方で、アニマティクス（チェック用の仮成果物）制作時のワークフローについては、Motion Builder作業者がMayaへの移植の手間をかけなくても済むように、MotionBuilderから直接データを出力しても良いようにしました。

MotionBuilderからMayaへのアニメーション移植

MB to Mayaワークフローの実現にあたり、以下のワークフローの赤枠部分でMotionBuilderのアニメーションをMayaへ移植する必要があります。

この移植作業を手動で行った場合、非常に多くの作業コストがかかってしまうためツールによる自動化を検討することになりました。

MotionBuilderからMayaへアニメーションを転送するには、Motion BuilderのSend to Mayaという機能を使用しています。これにより、MotionBuilder上で選択しているノードから、Mayaのシーン内に存在している同名のノードに対してアニメーションを転送可能になります。Send To Mayaは、今回のツールによる自動化のコアとなっています。

自動化の全体的なフローとしては、まず作業対象のカットに登場する登場人物やプロップの情報が入っている香盤情報データベースの内容から、Create Layout SceneというツールでモデルデータをMotionBuilder上に読み込みます。そして、必要をレイアウト作業を行った後、今度はMaya上で同じくCreateLayoutSceneを使ってデータを読み込み、Send to Mayaを使ってMotionBuilderの作業内容をMayaへ転送します。最後に、Maya上でゲームの仕様に合わせた微調整を行い成果物が完成となります。

なお、先ほど名前が出た香盤情報データベースでは、各シーンにどのようなキャラクターやプロップ（小道具）が存在するのか、全てまとまっています。

MotionBuilderからMayaへのデータ転送の際、骨の構造とNamespaceを含めた名前を一致させた、双方に互換性のあるリグデータが必要になります。

MotionBuilderの骨構造が例として紹介されました。Mayaへ転送するために、アニメーションが関わる骨についてはMayaのデータと一致させています。

Maya側の骨構造も紹介がありました。Maya側では、CRAFTという独自のシステムでリグを構築しているとのことです。

モジュラーリギングシステム CRAFT と内製ツールの紹介

アニメーションの他にカメラのデータも転送する必要がありますが、こちらは別のフローで転送しているそうです。MotionBuilder上でのカメラの動きの作成にはEdge Cmaeraという独自ツールを使い、中間データである.CCF形式のファイルを使ってMayaへ転送します。Maya上では、ゲームの仕様に合っていない部分を補うため、別途コンバートツール使用しています。

アセットの種類によってMotionBuilderとMayaでの仕様が異なっているので、それを吸収できるように微調整を行っています。

先ほどの全体ワークフローからMB to Mayaに関わるタスクを抜き出し、それを作業者視点で並び替えたのが以下の図となります。

各ツールの設計時に注意したこととして、MotionBuilderとMayaの利用者双方が納得でき、各ツールの強みを活かせるようにしたことや、大規模プロジェクトということで作業者の入れ替わりが発生することを前提に引き継ぎがスムーズにできることなどを意識したとのことです。

このようなツールのパイプラインが必要になる理由として、メンバーにプロジェクトのルールを守ってもらえるようにするためという点が挙げられました。プロジェクトの課題を解決するためにルールを作っても、ルールを守るための難易度が高いとメンバーに守ってもらえません。守れないルールがあっても意味はないので、ツールパイプラインを作ってルールを守れるようにしたことが課題解決をするために非常に重要だったそうです。